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(57) ABSTRACT 

A computer method, system and program product for debug- 
ging and/or monitoring an instruction set and having an 
improved breakpoint handling mechanism involving a hard- 
ware debug register set (or like breakpoint register means). 
Instead of patching a break instruction into a debuggee 
instruction sequence, re-inserting the original instruction 
and then single stepping through that instruction before 
replacing it with the patch, the original instruction is left in 
place and continuous execution is resumed. Before resuming 
however, the breakpoint register is set so that the break 
instruction can be re-applied while a flag (eg the Intel RF 
flag) is set so as to prevent a hardware break before that is 
desired. 

7 Claims, 4 Drawing Sheets 
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STEP 1 



EXCEPTION DUE TO 
HARDWARE BREAKPOINT 



HARDEN LAST BREAKPOINT (PUT A 
BREAKPOINT INSTRUCTION AT THE OLD 
ADDRESS) 

*old_addr= bpjnst 



STEP 2 



RECORD BREAKPOINT JUST HIT 



STEP 3 



PROGRAM THE DEBUG REGISTERS FOR 
A HARDWARE INSTRUCTION BREAKPOINT 
AT THE ADDRESS OF THE INSTRUCTION 
WHICH CAUSED THE EXCEPTION 
(orig_addr) 



STEP 4 



PUT BACK THE ORIGINAL INSTRUCTION 
FOR THIS BREAKPOINT 

*orig_addr=orig_istr 



STEP 5 




SET RESUME FLAG IN EFLAGS 
SET PC «- orig_addr 



STEP 6 
STEP 7 



FIG.4 
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METHOD, SYSTEM AND PROGRAM 
PRODUCT COMPRISING BREAKPOINT 
HANDLING MECHANISM FOR DEBUGGING 
AND/OR MONITORING A COMPUTER 
INSTRUCTION SEQUENCE 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The invention relates to a method, system and program 
product for debugging and/or monitoring a computer 
instruction sequence. The term * program product' here 
means a body of computer code stored by a machine 
readable storage medium such as a CD Rom or one or more 
floppy disks, or made available for downloading from a 
remote computer site. The computer code may form part of 
a computer program compiler, or it may be implemented as 
a debugger which stands alone or which is integrated into or 
provided as an add-on with another program, for example an 
editor/assembler or an operating system, or it may form part 
of one of various instrumentation tools for monitoring or 
analysing instruction sequences. 

A computer or computer based apparatus, eg an industrial 
automation system, comprises a central processor unit 
(CPU), often a microprocessor, and random access memory 
for holding data and instructions for controlling the CPU. A 
debugging program may be used to cause another program 
called the "debuggee", generally a relatively low level 
computer program, eg at the CPU kernel code level, to run 
on the CPU whilst monitoring the running of the debuggee 
program. One function of the debugger might be to cause the 
debuggee program to execute one step at a time (called 
"single-stepping") or to permit the debuggee program to run 
continuously until it reaches one or each of more than one 
breakpoint installed in the debuggee program by the debug- 
ger. At the or each breakpoint, or after each single step, the 
debugger may cause the display of values of parameters 
such as the contents of particular CPU registers, in order to 
help the user trace errors ("bugs") in the debuggee program. 
The means by which the debugger deals with such break- 
points is called herein the breakpoint handling mecha- 
nism". 

Note that it is possible to include breakpoints in the actual 
debuggee program but those breakpoints would need to be 
removed or made non-functional once the program has been 
debugged and the program is to be run normally. This 
invention is concerned with breakpoint handling by the 
debugger (or other tool or program incorporating a 
debugger). 

2. Related Art 

Thus, the basic functionality of breakpointing mecha- 
nisms in debuggers or various instrumentation tools is that 
of causing the generation of notifications/interceptions at 
desired points in an executing control flow sequence, where 
the points of interception are specified dynamically at run- 
time and not pre-programmed. 

To assist breakpoint handling, many modern CPU archi- 
tectures comprise breakpoint registers which can be used to 
make the processor generate an exception when the address 
programmed into one of the breakpoint registers is accessed, 
either for instruction execution or data access depending on 
the programmed settings. This facility is sometimes used to 
set breakpoints in code without having to patch the instruc- 
tion stream explicitly with a breakpoint instruction. In 
multitasking systems, the operating system usually has 
support for saving/restoring these registers in the time of a 
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context switch. However, since the number of such registers 
is usually very limited (eg four in the Intel Pentium 
platform), these are not sufficient for generic usage where 
the number of breakpoints required exceeds the number of 

5 registers available. 

A typical approach, therefore, is to fall back on putting in 
breakpoint instruction patches once all the breakpoint reg- 
isters have been used up for a process. In this case, the 
debugger replaces the instruction in the debuggee* s code 

10 stream where the breakpoint is desired with a breakpoint 
instruction. This will cause a trap whenever that instruction 
is executed. To continue program execution after breakpoint 
evaluation and processing is done each time the breakpoint 
is reached, the debugger puts back the original instruction at 
that point, makes the debuggee single-step this single 

15 instruction, and then replaces the breakpoint instruction (so 
that it is sure to be hit the next time the same code executes) 
before letting the debuggee continue at full speed. 

The above approach which is used in many debuggers 
today relies on single-stepping to continue execution past a 

20 breakpoint. One disadvantage of this approach is that single - 
stepping can be a little expensive in terms of increasing the 
debugged program's execution time. That is, the speed at 
which execution continues past an instruction where a 
breakpoint has been set. This is because when single step 

25 mode is turned on, there is an additional trap and hence 
switch from the debuggee to debugger on completion of the 
instruction, where the debuggee puts the breakpoint and then 
transfers back to the debugger, which would have been 
stopped till this gets done. 

30 Another related problem is that the method leaves open a 
window (albeit small) of potential breakpoint misses in the 
case of multi-threaded debuggee's, especially on multipro- 
cessor systems. This requires some mechanism for stopping 
all other threads/processors. 

35 Sometimes instruction emulation is used to avoid the need 
for single-stepping where possible, ie the debugger emulates 
the instruction instead of running it as a single step on the 
processor itself. However, this can be done only for a few 
instructions and has the disadvantage of dependence on 

40 knowledge of the instruction set of the processor. Another 
approach, used in some code patching dynamic instrumen- 
tation tools or dynamic debug APIs, is to actually relocate 
the original instruction to a different location in the debug- 
gee's address space and execute it from there, so that it is not 

45 necessary to put the original instruction back in its proper 
place. This avoids some of the problems cited earlier with 
in-place execution. However, transparent relocation is not 
very easy to achieve in all cases, is again dependent on 
knowledge of the instruction set of the processor, and can 

50 have unexpected side-effects in case of dependencies on the 
actual instruction address values that are hidden with the 
code/system logic. 

SUMMARY OF THE INVENTION 

55 In general terms the invention comprises a method, sys- 
tem and program product for operating a computer 
processor, which processor is coupled to memory means and 
which comprises breakpoint register means implemented as 
hardware in the processor. The invention comprises: 
60 (i) storing, at respective addresses of said memory means, 
a sequence of processor instructions to be processed by 
the processor; 

(ii) replacing one of said instructions in said sequence 
with a break instruction; 
65 (iii) supplying said sequence of instructions including the 
break instruction in place of the said one instruction to 
said processor; 
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(iv) when the break instruction has been acted upon by the 8. Continue debuggee 

processor, entering the address of the break instruction Note: If the same point is hit again, then just steps 7 and 

in said breakpoint register means; 8 are enough (assuring that as on Intel, the PC is already set 

(v) replacing the said one instruction at its original to the faulting instruction's address which would be the 
address; and 5 same as the original instruction; if not then step 6 might be 

(vi) causing the processor to resume on-going processing needed too). 

of the remainder of the sequence of instructions from Even a single breakpoint register is sufficient for this 

and including said one instruction. optimization to be possible. All that is happening is the delay 

Thus, the breakpoint register means is used for a purpose of setting back the breakpoint instruction as far as possible, 

that is different to the prior art. The restoration of the 10 thus simplifying the control flow involved in getting the 

breakpoint instruction after execution past a breakpoint debuggee to run past the breakpoint, 

(after putting back the original instruction) is not done As long as there is an operating system support for 

immediately. This enables the omission of the single-step making the breakpoint register settings effective across all 

after restoring the original instruction in the sequence processors that the concerned process is executing on, this 

described earlier. Instead, at that time, a breakpoint register also avoids the of potential breakpoint misses 

is used to set an instruction breakpoint at that address, and described earlier . since m t eraa lly this still involves stopping 

then a flag (eg the RF flag in Intel) is set m the processor to othef threads whik these ^ ftfe ^ cfa ^ {h[& fa 

ensure that the original instruction can execute without , * * -c * u • ic 

- , . . , 6 , . tA „ .. .. perhaps not a significant benefit m itself except m cases 

faulting right away, and yet cause a fault the next time the « . # t* <_ • . * , . it _ . . , 

• * * > *i * *• iU , , t * i 20 where the instruction being single-stepped is one that takes 

same point is hit. The next time the debugger gets control . . . ✓ . * *\ 

, r . . . . . - , ..v • £ a long time to complete (eg if it causes a page fault), 

(say, when another breakpoint is hit) in the same process ^ ■ , . v . . * , * 

context, the breakpoint instruction can be put back (herein N ° te tha u l breakpoint execution may be faster as a result of 

this is called "hardening" of the breakpoint), so that the av0ldm g tne single-step. [The gain in speed may be more 

breakpoint register is free for the next use. perceptible in conditional breakpoint evaluation situations, 

Summarising the prior art method, to continue after 25 especially if the point happens to be in a loop, even more so 

processing a breakpoint, the following sequence of actions m non-interactive debugging/instrumental tools]. The opti- 

are carried out: misation benefits the most frequently hit breakpoints (ie 

1. Stop other threads (or stop other processors and disable wheD ^ same breakpoint is hit repeatedly in succession 
interrupts, if this is a kernel debugger) without other intervening breakpoints) by its very nature, 

2. Put back original instruction rather than havin S the user or even the debu gS er V™&™ 
„ „ . , , , t t . . . - trying to decide which breakpoints to set via hardware 

3. Set the debueeee s program counter to the address of L , . . • . . . r 

me u.u^ c yiv&i«ui wuuiw iu iu auui » breakpoint registers to improve performance, 

the original instruction ^ r c u «f * i • a u 

°^ The performance benefits of making more debug registers 

4. Smgle-step the debuggee (give back control to the availaWe would ^ ^tibutoi more effectively across all 
debugger after the ongmal mstruction is executed) « breakpoints if ^ above steps are extended to use up all 

On completion ot single-step (notification via an , , . . . . . . . - . . t , 

. x r & r \ available breakpomt registers before attempt to reuse the 

exception): . , 9 

. register. 

5. Turn off single-step Not having tQ 51^.5^ may simplify the manage- 

6. Set the breakpomt back again ^ m ent of breakpoint state information in some cases. For 

7. Resume other threads (or resume other processors and example, with the single-step based approach, global state 
enable interrupts back again in the case of kernel may be required for tracking the currently executing break- 
debuggers) point across the execution of the original instruction, espe- 

8. Continue debuggee cially in the case of kernel debuggers, where interrupts may 
By comparison, the method to be described in the fol- 45 have to be disabled right through the single-step to avoid 

lowing detailed description comprises the following steps: nested execution complexities. In embodiments of the 
1. Harden previous breakpoint if any (if it is different from invention described herein, the main global state to be 
the current one) ["Hardening" involves putting back the maintained is for remembering the last non-hardened break- 
breakpoint instruction at the previous breakpoint point register at any point, while the breakpoint is hardened 
location] 50 only before the next time there is a need for the breakpoint 
2 Stop other threads register. Problems may arise with kernel breakpoints in 
3! Set up an instruction breakpoint register for the current ? a 8 eable „ ke ™ el «** * *• ^xt breakpoint occurs in an 
breakpoint (across processors on a symmetric multi- m , term Pf handler or s ° me P la <* * he . re P»ge faults cannot be 
processor system (SMP) if there were threads in this tak . eQ - To C0 ™ "f, ^J""*""* of » he ™ l ™ br f ak " 
process running on the other processors-this might 55 P olnl ^ be ^ dela ^ " I ? tto »»y. tf « 15 P°^ lbIe t0 
involve sending an IPI in the case of kernel debuggers). c°mein the ™y of the page fault handling code to make sure 
. . , jk at ^ breakpoujt 1S hardened before the page can actually 

4. Resume other threads . , r . 

be Recessed next 

5. Put back the original instruction Note that the method descr ibed herein relies on architec- 

6. Set the debuggee's PC to the address of the original 60 tures that have debug/breakpoint registers. In addition, for 
instruction an architecture where the breakpoint fault happens before 

7. Set a special processor flag (RF or Resume flag in Intel) the execution of the specified instruction, there should be 
in the debuggee's context for suppressing the break- some hardware support for a mechanism to delay the effect 
point exception for just the next executing instruction of the breakpoint register settings to immediately after the 
[This needs to be done so that the original instruction 65 instruction that caused that just trapped (ie a provision for 
can get executed as intended without faulting right- explicitly setting something like an RF flag in Intel or the 
away] PSW Z bit in HP PA-Risc). 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a simplified diagram of a computer system; 

FIG. 2 is a diagram for showing the contents of hardware 
registers of a CPU of the FIG. 1 system; 

FIG. 3 is a simplified diagram illustrating the interaction 
between hardware levels; and 

FIG. 4 shows a flowchart for a breakpoint handling 
mechanism. 

DETAILED DESCRIPTION 

FIG. 1 shows one embodiment of a computing environ- 
ment in which the present invention may be implemented. 

This embodiment comprises a so-called stand alone com- 
puter 1, ie one which is not permanently linked to a network, 
including a display monitor 2, a keyboard 3, a 
microprocessor — based central processing unit 4, for 
example an Intel Pentium processor, a hard-disc drive 5 and 
a random access memory 6 all coupled one to another by a 
connection bus 7. The keyboard 3 is operable for enabling 
the user to enter commands into the computer along with 
user data such as a search query. As well as keyboard 3, the 
computer may comprise a mouse or tracker ball (not shown) 
for entering user commands especially if the computer is 
controlled by an operating system with a graphic user 
interface. 

To introduce program instructions into the computer 1, ie 
to load them into the memory 6 and/or store them onto the 
disc drive 5 so that the computer begins to operate, and/or 
is made able to operate when commanded, in accordance 
with the present invention the computer 1 comprises a 
CD-ROM drive 8 for receiving a CD-ROM 9. 

In addition to the CD-ROM drive 8, or instead of it, any 
other suitable input means could be provided, for example a 
floppy-disc drive or a tape drive or a wireless communica- 
tion device, such as an infrared receiver (none of these 
devices being shown). 

Finally, the computer 1 also comprises a telephone 
modem 10 through which the computer is able temporarily 
to link up to the Internet via telephone line 11, a modem 12 
located at the premises of an Internet service provider (ISP), 
and the ISP's computer 13. 

The following describes how an embodiment of the 
invention can be implemented on the Intel Pentium plat- 
form. 

Hardware Debugging Feature 

The Intel Pentium processor provides the following hard- 
ware debugging features (refer FIG. 2): 

A breakpoint instruction WT3): When this instruction is 
executed, the processor generates a breakpoint trap 
exception (Interrupt 3). When the trap happens, the 
saved instruction pointer (EIP register) points to the 
instruction following the breakpoint instruction. 

Single stepping mode: When the TF bit (trap flag) in the 
processor's EFLAGS register is set, then the processor 
generates an exception (Interrupt 1) after the execution 
of every instruction. 

Debug registers: A set of registers (DRO-DR7) are used 
for specifying hardware breakpoints. These include 4 
debug address registers (DRO-DR3), each of which can 
be programmed with a memory (or I/O) location 
address signifying an instruction or data breakpoint. 
The processor generates an exception when a memory 
I/O operation takes place on one of these addresses. 
Each of the 4 registers can configured for either an 
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instruction or a data breakpoint. For instruction 
breakpoints, the exception is generated just before the 
execution of the instruction at the specified location. 
When the exception happens, the save instruction 
5 pointer (EIP register) points to the breakpoint 
instruction, which was about to execute. 
The debug control register (DR7) settings can be used to 
specify the type of the breakpoint (none, instruction, data 
reads, data reads/writes) for each of the 4 registers. 
10 When a debug exception happens, the debug status reg- 
ister (DR6) indicates the conditions which caused the excep- 
tion. The remaining debug registers, DR4 and DRS are 
reserved. 

Resume flag for breakpoint fault suppression: When the 
RF bit (resume flag) in the processor's EFLAGS reg- 
15 ister is set, then hardware breakpoint faults are sup- 
pressed for the next instruction. This enables the debug 
exception handler to resume program execution from 
the breakpointed instruction without having it generate 
a breakpoint fault again on the same instruction. The 
20 RF flag is set by the IRETD instruction to the value 
specified by the saved copy of the EFLAGS register 
(which the exception handler should have modified to 
the desired value) in order to disable the generation of 
the instruction breakpoint exception on the instruction 
25 immediately following the IRETD. The processor 
clears the RF flag at the successful completion of every 
instruction (except for the ERET instruction, and 
instructions resulting in a task-switch). This means that 
the breakpoint settings are activated back again right 
30 after the breakpointed instruction is executed. 
Steps Proposed 

The following explains how the above features could be 
used in implementing the suggested approach in a user mode 
debugger on this platform: 

It is assumed, for ease of explanation, that the debug 
35 address register DR3 is available for this purpose (we could 
reserve any debug register and use it instead). 

Refer to FIG. 3 for an illustrative representation of the 
system. It is the operating system that directly deals with the 
hardware registers, loading them from the process context 
40 information saved. The debugger makes use of operating 
system services to manipulate the debuggee's process con- 
text and code stream. 

1. Setting a Breakpoint 

A breakpoint is set at a specified location by replacing the 
45 instruction at that address with a breakpoint instruction (INT 
3) and saving the original instruction. This is the same as the 
way it is typically done in existing debuggers. 

2. When a Breakpoint Exception Takes Place: 
The following are the steps to be followed: 

50 (a) Complete desired breakpoint handling (depends on 
required debugger logic). For conditional breakpoints 
this could just be a check for the condition, 
(b) Now, to continue execution after the desired process- 
ing is complete and referring to the flow chart of FIG. 

55 4 where the step numbers refer to the step numbers 
given below: 

If this is a trap due to the execution of a breakpoint 
instruction (Interrupt 3), then: start from step 1. 
If this is due to a hardware instruction breakpoint fault 
60 (Interrupt 1), then start from step 7. 

Step 1 Is the breakpoint register in use, ie is there an 
earlier breakpoint to harden in this process context? If yes, 
then continue to step 2, else go to step 3. 
Step 2 Harden the last breakpoint by replacing the instruc- 
65 tion at the old address (as set in DR3, or saved as part of last 
active breakpoint information) with a breakpoint instruction 
(INT3). 



03/19/2004, EAST Version: 1.4.1 



US 6,71 

7 

Step 3 Record the breakpoint just hit as the last active 
breakpoint. 

Step 4 Set up an instruction breakpoint register in the 
debuggee's context for the current breakpoint by setting 
DR7 to enable instruction breakpointing via DR3, and 
loading the instruction's address into DR3. (This should be 
done in way that takes effect for processors which could be 
running threads from this process in case of an SMP system.) 

Step 5 Put back the original instruction for the breakpoint 
location (which was saved earlier). 

Step 6 Set the debuggee's EIP to the address of the 
original instruction (by making changes to saved EIP reg- 
ister context for the thread). 

Step 7 Set the RF flag in the saved EFLAGS context for 
the thread to suppress the breakpoint exception for the 
instruction that executes just after the context is restored. 

Step 8 Let the debuggee resume execution. 

To do this, the other threads might need to be stopped and 
resumed so that the corresponding processor registers get 
refreshed with the changes to the debug register context 
settings for the process. It is excepted that the operating 
system saves/restores debug register context across process 
context switches. If this happens at a thread level, then the 
debug register context changes for setting the new instruc- 
tion breakpoint will have to be effected on all the thread 
contexts for that process. 

It is possible for a context switch to happen just before 
execution continues past a breakpoint and then a different 
breakpoint gets hit in another process context, requiring 
hardening of the earlier breakpoint. In this situation, context 
switches to the original point, executing the breakpoint 
instruction and thus enters the breakpoint handler again. 
However, since the debug register settings will still to 
present, it is possible to distinguish this situation from a 
genuine breakpoint and simply ignore it. 

The above example is in the context of a user level 
debugger. The same approach could be applied to a kernel 
debugger too, its only that in this case it is the kernel context 
itself and processor registers that are directly modified, and 
that an IPI (Inter-processor interrupt) may be required to 
effect changes in the debug registers on all the processors. 
Another requirement in that case is that at least one debug 
register should remain set across all process contexts and not 
be reloaded during a context switch. 

Whilst a particular preferred embodiment of the invention 
has been shown and described herein by way of example, it 
will be understood by persons skilled in the art that 
modification, developments and other changes in form and 
detail may be made without departing from the spirit and 
scope of the invention as defined in the appended claims and 
equivalents thereof. 

The focus of the invention is usage of the breakpoint 
register to avoid the overhead of having to single-step, the 
"hardening" of the previous breakpoint to deal with the 
problem of limited breakpoint registers and also ensuring 
optimization for breakpoints that get hit repeatedly in 
sequence. It is not absolutely necessary to stop all the other 
threads at the same time. It will usually be necessary to 
ensure that the debug register settings are effected in all 
other thread contexts before proceeding to the next step. 

I claim: 

1. A method for operating a computer processor, which 
processor is coupled to memory and comprises breakpoint 
register means implemented as hardware in the processor, 
such breakpoint register means including a breakpoint reg- 
ister for holding an address and means for causing an 
exception in response to the processor accessing an address 
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in the memory corresponding to the address stored in the 
breakpoint register, the method comprising the steps of: 

(i) storing at respective addresses of said memory a 
sequence of processor instructions to be processed by 

5 the processor; 

(ii) replacing one of said processor instructions in said 
sequence with a break instruction, wherein in step (i) 
the one of said processor instructions was stored in a 
certain one of the addresses, and wherein, the replacing 

to includes storing the break instruction in the memory at 
the certain address in place of said one processor 
instruction; 

(iii) supplying said sequence of processor instructions, 
including the break instruction in place of the said one 

15 processor instruction, to said processor; 

(iv) when the break instruction has been acted upon by the 
processor, entering the certain address in said break- 
point register; 

(v) re-inserting the one of said processor instructions in 
20 the memory at the certain address; and 

(vi) causing the processor to resume on-going processing 
of a remainder of the sequence of processor instructions 
from and including said one processor instruction. 

2. A method according to claim 1, including, between 
25 steps (v) and (vi) of the method, the steps of: 

(vii) setting a program counter of the processor to the 
address of said one processor instruction; and 

(viii) setting a flag of the processor for causing an effect 
30 of the entry in the breakpoint register means to be 

suppressed whilst said one processor instruction is 
processed by the processor. 

3. A method according to claim 1, wherein the method is 
carried out in conjunction with controlling the processor 

35 using an operating system comprising a kernel or nucleus 
that handles multiple instruction threads and the method 
further comprises the steps of: 

(ix) before step (iv), ensuring that all instruction threads 
being handled by the kernel or nucleus at that time are 

40 stopped from being processed by the processor; and 

(x) between steps (iv) and (v), causing the processor to 
resume the processing of said instruction threads. 

4. A computer system comprising memory and a central 
processor unit that includes a hardware implemented break- 

45 point register means, such breakpoint register means includ- 
ing a breakpoint register for holding an address and means 
for causing an exception in response to the processor access- 
ing an address in the memory corresponding to the address 
stored in the breakpoint register, the system comprising an 

50 operating program stored by the memory and operable for 
controlling the computer system and also comprising a 
program including a breakpoint handling mechanism and 
operable for one of debugging, monitoring, analysing and 
tracing a debuggee program to be debugged, monitored, 

55 analyzed or in which program errors are to be traced, the 
debuggee program including a sequence of debuggee pro- 
gram instructions stored at respective addresses of said 
memory, the breakpoint handling mechanism comprising: 

(a) replacing means for replacing one of the instructions 
60 in the debuggee program with a break instruction, 

wherein the one of the debuggee instructions was 
stored in a certain one of the addresses and the replac- 
ing includes storing the break instruction in the 
memory at the certain address in place of the one 
65 debuggee instruction; 

(b) means for causing the debuggee program to run until 
the break instruction is reached; 
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(c) means for entering the certain address in said break- 
point register when the break instruction has been acted 
upon by the processor; 

(d) means for re-inserting the one of said debugee instruc- 
tions in the memory at the certain address; and 

(e) means for causing the processor to resume on-going 
processing of a remainder of a the debuggee program 
from and including said one debugee instruction. 

5. A system according to claim 4, wherein said means for 
causing the processor to resume on-going processing of the 
remainder of the debuggee program includes means for 
setting said program counter to the address of said one 
debugee instruction and means for setting a flag of the 
processor for causing the effect of the entry in the breakpoint 
register means to be suppressed, whilst said one debugee 
instruction is processed by the processor. 

6. A system according to claim 5, wherein said operating 
program comprises a kernel or nucleus for handling multiple 
instruction threads forming concurrent user processes at the 
level of an operating program shell, and wherein said means 
for causing the debuggee program to run until the break 
instruction is reached includes means for ensuring that all 
instruction treads being handled by the kernel or nucleus are 
stopped, the system further including means for ensuring 
resumption of said multiple instruction threads before the 
said one debugee instruction is re-inserted by the 
re-inserting means. 

7. A computer program product having a computer read- 
able medium with a computer program recorded thereon for 
operating a computer processor, which processor is coupled 
to memory and comprises a breakpoint register means, such 
breakpoint register means including a breakpoint register for 
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holding an address and means for causing an exception in 
response to the processor accessing an address in the 
memory corresponding to the address stored in the break- 
point register, said computer program comprising: 

(i) computer program code means for storing at respective 
addresses of said memory a sequence of processor 
instructions to be processed by the processor; 

(ii) computer program code means for replacing one of 
said processor instructions in said sequence with a 
break instruction, wherein the computer program code 
means in (i) is operable to store the one of said 
processor instructions in a certain one of the addresses, 
and wherein the replacing includes storing the break 
instructions in the memory at the certain address in 
place of said one processor instruction; 

(hi) computer program code means for supplying said 
sequence of processor instructions including the break 
instruction in place of the said one processor 
instruction, to said processor; 

(iv) computer program code means for entering the cer- 
tain address in said breakpoint register when the break 
instruction has been acted upon by the processor; 

(v) computer program code means for re-inserting the one 
of said processor instructions in the memory at the 
certain address; and 

(vi) computer program code means for causing the pro- 
cessor to resume on-going processing of a remainder of 
the sequence of processor instructions from and includ- 
ing said one processor instruction. 
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